Industrial robots perform a variety of tasks involving the movement and manipulation of physical objects. A typical industrial robot may, for example, have one or more arms, equipped with grippers, that allow the robot to pick up objects at a particular location, transport them to a destination location, and put them down in accordance with particular coordinates, thereby, for example, stacking them or placing them into cardboard boxes present at the destination location.
Controllers for existing industrial robots are typically programmed in languages that specify exact positions and trajectories for the robot arm(s). During execution of a programmed task, the robot arm moves a reference coordinate associated with its most distal link to an exactly specified new position, following an exactly specified trajectory. The success of existing industrial robots is due to their operation in constrained environments, which allows the person programming the robot—who is usually involved in the process of structuring the robot's workspace—to predict, with high confidence, which objects will be present in the workspace at all times, and where they will be located. As a result, moving the reference point on the robot arm to particular coordinates, via particular trajectories, and then opening or closing the gripper of the robot (or applying or releasing a suction gripper), lead to real-world actions that achieve the task desired of the robot.
A six-dimensional vector can be used to uniquely specify the reference point in three-dimensional space, along with the orientation of the most distal link. Thus, if the robot arm itself has six or fewer degrees of freedom, that vector uniquely determines the settings for all the joints of the robot. If the robot arm has more than six degrees of freedom, further specification of the desired pose of the arm is required to remove any ambiguity.
Recent programming systems for industrial robots have input layers that circumvent exposing the programmer to the six-dimensional vectors, with varying degrees of success. In one approach, the end points of the trajectories are set by physically moving the arm to a desired pose and position and then causing the robot to record that position. Various methods for moving the arm are used in practice. The most common method utilizes an external teaching pendant, i.e., a handheld control terminal, which is plugged into the robot controller only during the teaching phase. The pendant usually includes an LCD screen, a joystick or similar steering device, one or more buttons, and sometimes a full keyboard, which collectively allow the user to control and move the robot. Another technique involves equipping the most distal link of the robot arm with a load cell, and having the user switch the arm into a mode in which it responds to forces applied to the load cell. In this approach, the user guides the robot to a desired position by hand, possibly adjusts with the teaching pendant, and then gives a command to record the position. The command may be given, for example, via a button on the pendant or via speech.
Regardless of the input method used, conventional industrial robots are programmed for vectorized movement in a coordinate system relative to the robot. While some programming systems allow for inputs from external sensors to identify external locations, these, too, are translated into the coordinate system of the robot in order for the robot to move its reference point to the desired location. The translation relies on knowledge of the location and orientation of the robot relative to the external sensor; typical positional-accuracy requirements for industrial robots are in the sub-millimeter range. Consequently, if either the robot or the external sensor is moved, even if only a small distance, relative to the objects in the world, the robot will move its reference point to the wrong place in the world and, thus, fail at its task.
Further, while existing robots may use external-sensor input to detect, e.g., objects to be manipulated or equipment such as boxes or conveyor belts, such input is merely used as a gating signal for the next task. The robot's interaction with the external objects itself must be carefully programmed in terms of coordinates and trajectories, and only if the world is ordered as expected by the programmer will the robot carry out its task successfully, i.e., without collisions or misplacements. For example, in order to cause a robot to place objects in a cardboard box, e.g., in a three-by-four grid, the programmer has to specify the twelve sets of coordinates corresponding to the locations in the box where objects are to be placed. Further, to ensure that neither the robot itself nor the grasped objects will collide with the side of the box, the programmer has to specify the order in which the twelve spots are to be filled, as well as the approach directions and trajectories (which might be different for objects placed against the boundary of the box as opposed to objects placed at the center). Of course, the robot will only be able to pack objects within a narrow size range. If an object is larger, or differently shaped, than the programmer assumed, the process will be unsuccessful because, once again, the robot's actions have been so highly constrained.
Similarly, when programming a robot to pick up objects from a conveyor belt, the programmer relies on a controlled, predictable operation of the conveyor belt. Typically, an external sensor, such as a break-beam sensor attached to the conveyor, allows the robot to detect objects on the conveyor. Any time the beam is broken, an object of the desired type moving along with the conveyor is assumed to be the cause of the break. The speed of the conveyor is implicitly coded into the robot program in the form of a coordinate for a pick-up location and a time delay measured from the time of the break. An explicit velocity vector may also be included, allowing the robot gripper to move at the same velocity as the object on the conveyor belt when the gripper is activated. As long as the assumptions about the conveyor position and velocity are correct, these specifications guarantee that the robot will pick up the desired objects from the moving conveyor; otherwise, because the robot possesses no task-level knowledge, it will fail.
Robot-control programs usually include control logic that deals with error conditions. Due to the coordinate-level specificity that generally governs the robot's behavior, the response options in case of an error are limited. For example, the robot may simply stop operating, and perhaps issue an error alarm, when an essential assumption underlying a particular programmed task is violated, or the world deviates otherwise from its expected state.
Accordingly, there is a need for robots that respond more flexibly to their surroundings and tolerate greater deviations from default assumptions, and which, preferably, may be used and configured for execution of complex tasks based on intuitive interactions.